Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1199/1059

Internet Message Format | 1994-08-27 | 5.7 KB

From: [e-mail] (Mark Miller)
Subject: A few questions...
Date: Fri, 18 Feb 1994 21:07:49 -0700 (MST)
Mime-Version: 1.0

I've got a few more questions for ya (and they probably ain't the last).

When I put something in ~/bin and try to run it, it says:
U:/USR/USERS/MTM/BIN\<file>: File not found.

This REALLY confuses me, because it obviously was able to find the file
that I'm trying to run, but for some reason it says "I can't find it!"
I don't have this problem with any other path really.  I've noticed
this sometimes happens on Unix systems, and it's usually because of
some bug in a shell script I wrote.  It doesn't just do this with
scripts though.  It also does this with binaries that I put in there,
at least I'm pretty sure it does.  u:/usr/users/mtm/bin IS in my PATH.
Another thing I just noticed as I was writing you this is that it also
does this when there is not enough memory to run the application.  At
least it seems to be this way.

BASH seems to have a very primitive hashing system, compared to what
I'm used to.  Sometimes I end up in /bin, and I run ls.  Then I change
directories, and try to run ls again, and it says "ls.ttp: File not
found."  When I check its hash table, it just says "ls.ttp" not
"u:/bin\ls.ttp" (the normal form).  In these situations I just do
hash -r and that clears up the problem.  It's just very irritating.
Is there a more user-friendly way to handle this?  Is there some way
to prime the hash table automatically like when the shell is first
started up?

I am also interested in distributing your MDK around.  I got the old
version several weeks ago.  It's probably been more than a month.
You've said that a new version will be coming out soon.  I've still
got most of the disks on my computer, and I would rather not just
redownload the brand new MDK.  I assume it just contains some
refinements?  Could you tell me what I would need to download to
supplement what I already downloaded a while back, to upgrade the
package?  I know for example that I would need to replace Disk 1,
since as you've said, some things about it have been updated.  Also,
when and where can I find the new MDK?  I haven't noticed it on
atari.archive recently.

I remember from your documentation you said that you would post
patches to your MDK named "update<something>".  I noticed that in the
Mint/Tos directory there is a directory called Updates, which seems to
contain a bunch of patch files for various applications.  Are these
the ones you were talking about, or were you talking about the Updates
directory under Mint/Tos/Distrib_kit?

Also, I just noticed I did something that caused a segmentation fault
(and it didn't crash the system. YEAH!!!!!), and it was while I was
trying to use "limit" to execute a TTP program.  I've noticed that the
few regular TTP programs I've tried generally want all the memory to
themselves, and if I try to limit it with "limit" they get all bent
out of shape.  One program I tried was XYZ.TTP.  Every time I used
"limit" with it, it told me it didn't have enough memory to allocate
the buffer.  It seems that it does some kind of low-level call (below
MiNT level or something) to determine how much free memory there is
and expects to get that much.  When it doesn't, it complains.  The
process that seg-faulted was MG_ST, 'cause it apparently also wants
all the remaining memory to itself, and crashes if it doesn't get all
it wants.  What I'm wondering is why is this happening?  Isn't the
purpose of "limit" to fool the called application into believing it
only has so much memory?

One thing that I have liked about MiNT is if a system error occurs it
tells me in almost plain English, and doesn't crash the system.  For a
long time I've been running an AUTO program called Antibomb which kind
of does the same thing.  It puts the system error in a dialog box and
allows some options like continuing or rebooting.  The thing is is
usually the best option to take is to reboot, since the system still
gets messed up after a system error.  Is MiNT better about this?  Is
it like Unix where if you cause a system error, it tells you what
occured, but averts a crash of the entire system and you don't need
to reboot?  I like to program and this would be a big help, since if
there's a bug in my program, it usually causes a system error of some
sort, and I end up rebooting after each one which slows me down.

Speaking of XYZ.TTP, I've been REALLY hankerin' to get my hands on
some kind of MiNT-compiled software (or just regular TOS software that
will run under MiNT) that will allow me to upload/download files
to/from a system I am calling with my modem.  It looks like there is a
standard package nowadays on Unix systems called "rz" and "sz" (these
contain variations which also allow x-modem and y-modem transfers)
which by default transfer files using z-modem protocol.  Is there
anything like this available?  I know that there is a vt52 terminal
program under MGR, but I haven't really gotten it to work, and I don't
know if it has binary file transfer capabilities.

I was thinking of using such a transfer program in conjunction with
"tip".

I have been using elvis and I like it quite a bit, since it's more
user-friendly than normal vi.  An irritating "feature" about it though
is it seems I can only use it on the partition in which it is
installed, E:, because it seems to not pay attention to the TMP or
TEMPDIR environment variables.  I have both of them set to u:/tmp.  It
seems to just look for /tmp, so if the CWD is d:/<whatever>, it can't
find the tmp dir.  Is there a way to fix this so it'll always look for
u:/tmp?

Also, could you give me Eric Smith's e-mail address?  I can't seem to
find it in my documentation anywhere.

Thanks,
---Mark
[e-mail]